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AFTER FINAL EXPEDITED PROCEDTJR^ 

REMARKS 

Claims 1 to 31 were pending in the application at the 
time of examination. Claitns 1 to 31 remain rejected as 
anticipated. 

Claims 1 to 31 remain rejected under 3 5 U.S. C. § 102(e) 
as being unpatentable over U.S. Patent Application 
Publication No. 3005/0138354 of Salta, hereinafter referred 
to as Saltz. 

Appliccint respectfully continues to traverse the 
anticipation rejection of Claim 1. Applicant respectfully 
notes that elements in Saltz must be given a consistent 
definition and that Saltz must be considered -as a whole. 
Saltz is careful to distinguish between applets, which the 
rejection identified as reading on "application" in Claim 1, 
and firewalls. Accordingly, as explained more completely 
below, the two cannot be interchanged. 

Saltz stated: 

[0050] As will be appreciated, the Java Card Runtime 
Environment™ (JCRE 208) can provide a firewall 
protection for the Java*^^ applets A, B, C, D, E, F and 
G. Moreover, the firewall protection provided by the 
Runtime Environment (JCRE 208) is configurable. This 
means that, among other things, the firewall protection 
does not have to be defined based on package boundaries 
that contain one or more Java™ applet. In other words, 
firewall protection does not have to be defined based 
on the packages 230, 232, and 324. The firewall 
protection can be configured using a firewall control 
block that is further illustrated (see for example PIG. 
3) , but first the configurable firewall will be further 
illustrated with respect to firewall boundaries that 
can be configured for various Java*^" applets. 

Thus, Saltz explicitly taught that the JCRE provides 
the firewall protection and that firewall protection is 
configurable. However, this teaches nothing about the 
applications of Saltz. The JCRE and applications are at 
fundamentally different programmatic levels. The rejection 
has cited no teaching in Saltz that Applets A, B, C, D, E. 
F, G and H are configurable or can be customized. 
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Claim 1 recites: 



configuring the application in accordance with the 
stored AID, wherein the application is configured in 
accordance with said at least one customization 
parameter 

A configurable firewall that ie part of the JCRE fails 
to teach configuring the applets of Saltz that the rejection 
identified as the applications. The fact thcit the firewall 
in the JCRE is configured does not change the application, 
it is the same application that it was before the firewall 
was configured- Therefore, Saltz fails to show "The 
identical invention ... in as complete detail as is 
contained in the ... claim." MPEP §2131, Bth. Ed., Rev. 3, 
p. 2100-76 (August 2005) . This alone is sufficient to 
overcome the anticipation rejection. 

Saltz does address that an AID is associated with the 
applet, but again Salt^ fails to teach "said AID corapriaea 
at least one customization parameter for the application to 
be installed ." The rejection cited the applets as being the 
application installed. Therefore, Saltz must teach that the 
AID for these applets includes a customization parameter. 
Saltz taught: 



[00631 As will he appreciated, similar to existing Java 
Card environments, the Application Identifier Data 

(AID) can be defined based on the ISO 7 BIS standard- 
ise 7B16 is a multipart standard that describes a broad 
range of technology for building smart card systems. 
ISO 7816-5 defines the AID (application identifier) 
data format to be used for unique identification of 
card applications (and certain kinds of files in card 
file systems) . The Java Card platform uses the AID data 
format to identify applets and packages . AIDs are 
administered by the International Standards 
Organization (ISO) , so they can be used as unique 
identifiers. 

[0064] As illustrated in FIG. 3E, the AID format used 
by the Java Card platform can be an array of bytes that 
is interpreted as two distinct pieces. The first piece 
is a 5-byte value known as RID (Resource Identifier) . 
The second piece is a variable length value known as a 
PIX (proprietary Identifier Extension) . A PIX can be 
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from 0 to 11 bytes in length • Thus an AID can be from 5 
to 16 bytes in total length. ISO controls the 
assignment of RIDs to companies, with each company 
obtaining its own unique RID from the ISO. Companies 
manage assignment of PIXs for AlDs using their own 
RIDs. In the Java platform, packages are uniquely 
identified using Unicode strings and a naming scheme 
based on Internet domain names . In the Java Card 
platform, packages and applets can be identified using 
AIDS. As such, each applet installed on. a Java Card 
technology enabled device has a unique AID. This AID is 
constructed similarly to & package AID . It is typically 
a concatenation of the applet provider's RID and PIX 
for that applet. (Emphasis Added.) 



Thus, at most Saltz taught that the AID has two parts 
as defined by the standard and that the AID is used for 
identifying an applet- This fails to teach or suggest 
anything about the AID including "at least one customization 
parameter for the application to be installed." 

Saltz, as quoted above, taught that the AID is used to 
identify the applet and so expressly taught away from using 
the Alb in customizing the applet as recited in Claim 1. 
Further, Saltz taught that the JCRE firewalls and not the 
applet used the AID in determining whether the firewall will 
permit an applet to access another applet. The rejection 
has cited no teaching that the applets are modified in 
anyway based upon the AID. Again, as previously pointed 
out, the rejection confuses configuration of the firewall 
with configuration of an application as recited in Claim 1. 
A broad interpretation of the claim language does not permit 
contradicting the explicit teachings of the reference . 

Claim 1 is specific on the actions taken: 



for one of the applets A to H has an AID with a customizable 



providing an application identifier (AID) for the 
application, wherein said AID comprises 'at least one 
customization parameter for the application to be 
installed; 



The AID is "for the application 
Accordingly, the rejection must cite 



to be installed." 

a teaching that an AID 
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parameter. The rejection has failed 



to make such a showing. 
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As quoted above Saltz taught the AID is defined in a 
conventional matter and failed to teach anything about 
customizing a particular parameter in any AID of Saltz - 

The rejection must Show that Salt 2 teaches that for one 
of applets A to H 

configuring the application in accordance with the 
stored aid, wherein the application is configrured in 
accordance with said at least one customization 
parameter , 

The rejection must cite a teaching that one of Applets A to 
H is configured in accordance with some ciastomixable 
parameter in the AID of Saltz. Such a showing has not been 
made . 

As noted above, Saltz expressly taught the firewall 
that is a part of the JCRE was configured and not the 
application that was configured- The rejection has cited no 
teaching of configuring an applet in Salta and instead cited 
to the configuration of the firewall, which Saltz and the 
rejection identified as being different from the applet that 
was identified as the application in the rejection. Further 
the AID is used for identification (See Pig. 5 of Saltz) and 
not for configuring the application as recited in Claim 1 . 

Applicant respectfully notes that one of skill in the 
art would not consider the firewall of the JCRE to be part 
of the applet and Saltz is careful to maintain the 
distinction. Accordingly, there is no basis for mixing and 
matching the features from the two different entities of 
Saltz as was done in the rejection- Such a modification of 
Saltz would be inappropriate for an obviousness rejection 
and so cannot be the basis for an anticipation rejection. 

Again, Applicant respectfully notes that in an 
anticipation rejection, it is not sufficient that a 
reference use some of the same terms as recited in 
Applicant claims, but rather the ^The identical invention 
must b© shown in as complete detail as is contained in the 

claim." MPEP §2131, 8th- Ed., Rev. 3, p.' 2100-76 
(August 2005) . Applicant has demonstrated that at multiple 
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levels Salt2 fails to teach rhe identical iziyentlon in as 
complete detail as contained in Claim 1. Applicant requests 
reconsideration and withdrawal of the anticipation rejection 
of Claim 1. 

With respect to claim 2, the rejection identifiea 
applets A to H as the applications. The rejection failed to 
cite any teaching that any of applets A to H was "an AID 
interpreter," With respect to Claim 3, the rejection has 
cited no teaching in Saltz of how an AID is stored and 
instead cites generally to Fig. 2 of Saltz. The rejection 
failed to cite any teaching of an applet storing anything on 
the smart card. With respect to Claim 10, the rejection has 
failed to cite any teaching of cryptographic .operations in 
the J^bstract of Saltz that: are related to the AID of Saltz. 

In addition, each of Claims 2 to 11 depend from Claim 1 and 
so distinguish over Saltz for at least the same reasons as 
Claim 1- Applicant respectfully requests reconsideration 
and withdrawal of the anticipation rejection of each of 
Claims 2 to 11- 

Claim 12 is an apparatus claim that includes "wherein 
the application is configured in accordance with said at 
least one customization parameter from the stored AID." 
Further, the rejection failed to cite any teaching of an 
apparatus for installing an application on a card. 
Paragraph [0047] describes the card and not how the 
information got onto the card. Element 204 of Fig. 2 is a 
reader side device and so teaches away from an installation 
apparatus. The above comments concerning the AID and the 
configuration of the application are incorporated herein by 
reference. As noted above, the rejection did not address 
these limitations. Applicant requests reconsideration and 
withdrawal of the anticipation rejection of Claim 12. 

Claims 13 to 19 depend from Claim 12 and so distinguish 
over Saltz for at least the same reasons as Claim 12. 
Applicant respectfully requests reconsideration and 
withdrawal of the anticipation rejection of each of 
Claims 13 to 19. 
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Claim 20 is an apparatus claim that includes 
limitations similar to those discussed above with respect to 
Claim 1 . Accordingly^ the above comments wit:h ' respect to 
Claims 1 are incorporated herein by reference. Applicant 
requests reconsideration and withdrawal of the anticipation 
rejection of Claim 20, 

Claim 21 is a computer product claim that includes 
limitations similar to those discussed above with respect to 
Claim 1. Accordingly, the above comments wit'h respect to 
Claims 1 are incorporated herein by reference. Applicant 
recpiests reconsideration and withdrawal of the anticipation 
rejection of Claim 21. 

Claims 22 to 31 depend from Claim 21 and so distinguish 
over Saltz for at least the same reasons as Claim 21. 
Applicant respectfully requests reconsideration and 
withdrawal of the anticipation rejection of each of 
Claims 22 to 31. 

Claims 1 to 31 remain in the application. For the 
foregoing reasons. Applicant (s) respectfully request 
allowance of all pending claims. If the Examiner has any 
questions relating to the above, the Examiner is 
respectfully requested to telephone the undersigned Attorney 
for Applicant (s) . 



CERXIFTCATK OFTRANSMISSTON 
I hereby cerrlfy thac chis correspondencQ Ig being 
facalinile transmitted ro the U-S- Potent and 
Trademark Offioo^ Fax NO- (571) 273-8300, Cti May 
4, 2Q0S. 



Mfty 4, 2006 

Da^e oC Signature 



Respectfully submitted, 

Forrest Gunnison 
Attorney for Applicant <s) 
Reg. No. 32,899 
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